Introdução

• A programação reativa é um paradigma de programação elegante e poderoso, mas pode ser desorientador no início porque é um paradigma muito diferente de escrever um script.

• A ideia-chave da programação reativa é especificar um grafo de dependências para que, quando uma entrada for alterada, todas as saídas relacionadas sejam atualizadas automaticamente.

A função do servidor

As entranhas de cada aplicativo Shiny são assim:

library(shiny)

ui <- fluidPage(
  # front end interface
)

server <- function(input, output, session) {
  # back end logic
}

shinyApp(ui, server)

O objeto ui que contém o HTML apresentado a todos os usuários do seu aplicativo.

• O ui é simples porque cada usuário recebe o mesmo HTML.

• server é mais complicado porque cada usuário precisa obter uma versão independente do aplicativo.

Para obter essa independência, o Shiny invoca sua função server() toda vez que uma nova sessão é iniciada.

• Quando a função do servidor é chamada, ela cria um novo ambiente local que é independente de qualquer outra invocação da função.

• Isso permite que cada sessão tenha um estado único, além de isolar as variáveis criadas dentro da função.

As funções do servidor usam três parâmetros: input, output e session.

• eles são criados pelo Shiny quando a sessão começa, conectando-se novamente a uma sessão específica.

Entrada

O argumento input é um objeto semelhante a uma lista que contém todos os dados de entrada enviados do navegador, nomeados de acordo com o ID de entrada.

• Por exemplo, se sua IU contiver um controle de entrada numérico com um ID de entrada de count, assim:

ui <- fluidPage(
  numericInput("count", label = "Number of values", value = 100)
)

Você pode acessar o valor dessa entrada com input$count.

• Ele conterá inicialmente o valor 100 e será atualizado automaticamente conforme o usuário altera o valor no navegador.

Ao contrário de uma lista típica, os objetos input são somente leitura.

• Se você tentar modificar uma entrada dentro da função do servidor, receberá um erro:

server <- function(input, output, session) {
  input$count <- 10  
}

shinyApp(ui, server)
#> Error: Can't modify read-only reactive value 'count'

Este erro ocorre porque input reflete o que está acontecendo no navegador, e o navegador é a “única fonte de verdade” do Shiny.

• Mais uma coisa importante input: é seletivo sobre quem tem permissão para lê-lo.

• Para ler de um input, você deve estar em um contexto reativo criado por uma função como renderText() ou reactive().

• Este código ilustra o erro que você verá se cometer este erro:

server <- function(input, output, session) {
  message("The value of input$count is ", input$count)
}

shinyApp(ui, server)
#> Error: Can't access reactive value 'count' outside of reactive consumer.
#> ℹ Do you need to wrap inside reactive() or observer()?

Saída

output é muito semelhante a input: também é um objeto semelhante a uma lista nomeado de acordo com o ID de saída.

• A principal diferença é que você o usa para enviar saída em vez de receber entrada.

• Você sempre usa o objeto output em conjunto com uma função render, como no exemplo simples a seguir:

ui <- fluidPage(
  textOutput("greeting")
)

server <- function(input, output, session) {
  output$greeting <- renderText("Hello human!")
}

A função de renderização faz duas coisas:

• Ele configura um contexto reativo especial que rastreia automaticamente quais entradas a saída usa.

• Ele converte a saída do seu código R em HTML adequado para exibição em uma página da web.

Como o input, o output é exigente sobre como você o usa. Você receberá um erro se:

• Você esquece a função render.

  server <- function(input, output, session) {
    output$greeting <- "Hello human"
  }
  shinyApp(ui, server)
  #> Error: Unexpected character object for output$greeting
  #> ℹ Did you forget to use a render function?

• Você tenta ler de uma saída.

  server <- function(input, output, session) {
    message("The greeting is ", output$greeting)
  }
  shinyApp(ui, server)
  #> Error: Reading from shinyoutput object is not allowed.

Programação reativa

Vejamos um exemplo simples:

ui <- fluidPage(
  textInput("name", "What's your name?"),
  textOutput("greeting")
)

server <- function(input, output, session) {
  output$greeting <- renderText({
    paste0("Hello ", input$name, "!")
  })
}

Se você executar o aplicativo e digitar na caixa de nome, verá que a saudação é atualizada automaticamente conforme você digita.

• Esta é a grande ideia do Shiny: você não precisa dizer a uma saída quando atualizar, porque o Shiny automaticamente descobre isso para você.

output$greeting <- renderText({
  paste0("Hello ", input$name, "!")
})

É fácil ler isso como “cole ‘hello’ e o nome do usuário e envie para output$greeting”.

• Mas esse modelo mental está errado de uma maneira sutil, mas importante.

O aplicativo funciona porque o código não diz ao Shiny para criar a string e enviá-la ao navegador, mas, em vez disso, informa ao Shiny como ele pode criar a string se for necessário.

• Cabe a Shiny quando (e mesmo se!) o código deve ser executado.

• Pense em seu aplicativo como fornecendo receitas ao Shiny, não dando comandos.

Programação imperativa x declarativa

• Na programação imperativa , você emite um comando específico e ele é executado imediatamente.

• Na programação declarativa, você expressa metas de alto nível ou descreve restrições importantes e confia em outra pessoa para decidir como e/ou quando traduzir isso em ação.

  • Este é o estilo de programação que você usa no Shiny.

Preguiça

Um dos pontos fortes da programação declarativa no Shiny é que ela permite que os aplicativos sejam extremamente preguiçosos.

• Um aplicativo Shiny só fará a quantidade mínima de trabalho necessária para atualizar os controles de saída que você pode ver atualmente.

• Essa preguiça, no entanto, vem com uma desvantagem importante que você deve estar ciente.

  • Você consegue identificar o que há de errado com a função do servidor abaixo?

server <- function(input, output, session) {
  output$greting <- renderText({
    paste0("Hello ", input$name, "!")
  })
}

Se você olhar de perto, poderá notar que escrevi greting em vez de greeting.

• Isso não gerará um erro no Shiny, mas não fará o que você deseja.

• A saída greting não existe, portanto, o código interno renderText() nunca será executado.

O gráfico reativo

A preguiça de Shiny tem outra propriedade importante.

• Na maioria dos códigos R, você pode entender a ordem de execução lendo o código de cima para baixo.

• Isso não funciona no Shiny, porque o código só é executado quando necessário.

• Para entender a ordem de execução, você precisa olhar para o gráfico reativo, que descreve como as entradas e saídas são conectadas.

Este gráfico informa que greeting precisará ser recalculado sempre que name for alterado.

Expressões reativas

Há mais um componente importante que você verá no gráfico reativo: a expressão reativa.

• uma ferramenta que reduz a duplicação em seu código reativo, introduzindo nós adicionais no gráfico reativo.

server <- function(input, output, session) {
  string <- reactive(paste0("Hello ", input$name, "!"))
  output$greeting <- renderText(string())
}

As expressões reativas recebem entradas e produzem saídas para que tenham uma forma que combine recursos de entradas e saídas.

Ordem de execução

É importante entender que a ordem em que seu código é executado é determinada exclusivamente pelo gráfico reativo.

• Por exemplo, poderíamos inverter a ordem das duas linhas em nossa função de servidor simples:

server <- function(input, output, session) {
  output$greeting <- renderText(string())
  string <- reactive(paste0("Hello ", input$name, "!"))
}

Esse código produz o mesmo gráfico reativo acima, portanto, a ordem na qual o código é executado é exatamente a mesma.

• Organizar seu código assim é confuso para humanos e é melhor evitar.

Expressões reativas

As expressões reativas são importantes porque:

• fornecem ao Shiny mais informações para que ele possa fazer menos recomputação quando as entradas mudam, tornando os aplicativos mais eficientes

• facilitam a compreensão do aplicativo por humanos simplificando o gráfico reativo.

As expressões reativas têm um sabor de entradas e saídas:

• Assim como as entradas, você pode usar os resultados de uma expressão reativa em uma saída.

• Assim como as saídas, as expressões reativas dependem das entradas e sabem automaticamente quando precisam ser atualizadas.

A motivação

Imagine que eu queira comparar dois conjuntos de dados simulados com um gráfico e um teste de hipótese.

• Por exemplo: freqpoly() visualiza as duas distribuições com polígonos de frequência , e t_test() usa um teste t para comparar médias e resume os resultados com uma string:

    library(ggplot2)

    freqpoly <- function(x1, x2, binwidth = 0.1, xlim = c(-3, 3)) {
      df <- data.frame(
        x = c(x1, x2),
        g = c(rep("x1", length(x1)), rep("x2", length(x2)))
      )

      ggplot(df, aes(x, colour = g)) +
        geom_freqpoly(binwidth = binwidth, size = 1) +
        coord_cartesian(xlim = xlim)
    }

    t_test <- function(x1, x2) {
      test <- t.test(x1, x2)
      
      # use sprintf() to format t.test() results compactly
      sprintf(
        "p value: %0.3f\n[%0.2f, %0.2f]",
        test$p.value, test$conf.int[1], test$conf.int[2]
      )
    }

Se eu tiver alguns dados simulados, posso usar essas funções para comparar duas variáveis:

    x1 <- rnorm(100, mean = 0, sd = 0.5)
    x2 <- rnorm(200, mean = 0.15, sd = 0.9)

    freqpoly(x1, x2)

    cat(t_test(x1, x2))

p value: 0.056
[-0.31, 0.00]

• Extrair código imperativo em funções regulares é uma técnica importante para todos os aplicativos Shiny: quanto mais código você puder extrair do seu aplicativo, mais fácil será entender.

O aplicativo

Gostaria de usar essas ferramentas para explorar rapidamente um monte de simulações.

• Um aplicativo Shiny é uma ótima maneira de fazer isso porque permite que você evite modificar e executar novamente o código R de forma tediosa.

Vamos começar com a interface do usuário.

• A primeira linha tem três colunas para controles de entrada (distribuição 1, distribuição 2 e controles de plotagem).

• A segunda linha tem uma coluna larga para o gráfico e uma coluna estreita para o teste de hipótese.

ui <- fluidPage(
  fluidRow(
    column(4, 
      "Distribution 1",
      numericInput("n1", label = "n", value = 1000, min = 1),
      numericInput("mean1", label = "µ", value = 0, step = 0.1),
      numericInput("sd1", label = "σ", value = 0.5, min = 0.1, step = 0.1)
    ),
    column(4, 
      "Distribution 2",
      numericInput("n2", label = "n", value = 1000, min = 1),
      numericInput("mean2", label = "µ", value = 0, step = 0.1),
      numericInput("sd2", label = "σ", value = 0.5, min = 0.1, step = 0.1)
    ),
    column(4,
      "Frequency polygon",
      numericInput("binwidth", label = "Bin width", value = 0.1, step = 0.1),
      sliderInput("range", label = "range", value = c(-3, 3), min = -5, max = 5)
    )
  ),
  fluidRow(
    column(9, plotOutput("hist")),
    column(3, verbatimTextOutput("ttest"))
  )
)

A função do servidor combina chamadas para funções freqpoly() e t_test() após extrair das distribuições especificadas:

server <- function(input, output, session) {
  output$hist <- renderPlot({
    x1 <- rnorm(input$n1, input$mean1, input$sd1)
    x2 <- rnorm(input$n2, input$mean2, input$sd2)
    
    freqpoly(x1, x2, binwidth = input$binwidth, xlim = input$range)
  }, res = 96)

  output$ttest <- renderText({
    x1 <- rnorm(input$n1, input$mean1, input$sd1)
    x2 <- rnorm(input$n2, input$mean2, input$sd2)
    
    t_test(x1, x2)
  })
}

• Você pode encontrar uma versão ao vivo em https://hadley.shinyapps.io/ms-case-study-1.

O gráfico reativo

Veja esta parte do código do servidor:

x1 <- rnorm(input$n1, input$mean1, input$sd1)
x2 <- rnorm(input$n2, input$mean2, input$sd2)
t_test(x1, x2)

Como um humano lendo este código, você pode dizer que só precisamos atualizar x1 quando n1, mean1, ou sd1 muda, e só precisamos atualizar x2 quando n2, mean2, ou sd2 muda.

• Shiny, no entanto, apenas analisa a saída como um todo, portanto, atualizará ambos x1 e x2 sempre que um de n1, mean1, sd1, n2, mean2 ou for sd2 alterado.
  

Você notará que o gráfico é muito denso: quase todas as entradas estão conectadas diretamente a todas as saídas. Isso cria dois problemas:

• O aplicativo é ineficiente porque faz mais trabalho do que o necessário.

  • Por exemplo, se você alterar as quebras do gráfico, os dados serão recalculados; se você alterar o valor de n1, x2 é atualizado (em dois lugares!).

Há uma outra grande falha no aplicativo: o polígono de frequência e o teste t usam sorteios aleatórios separados.

• Isso é bastante enganoso, pois você esperaria que eles estivessem trabalhando nos mesmos dados.

Simplificando o gráfico

Refatoramos o código existente para extrair o código repetido em duas novas expressões reativas, x1 e x2, que simulam os dados das duas distribuições.

• Para criar uma expressão reativa, chamamos reactive() e atribuímos os resultados a uma variável.

• Para usar a expressão posteriormente, chamamos a variável como se fosse uma função.

server <- function(input, output, session) {
  x1 <- reactive(rnorm(input$n1, input$mean1, input$sd1))
  x2 <- reactive(rnorm(input$n2, input$mean2, input$sd2))

  output$hist <- renderPlot({
    freqpoly(x1(), x2(), binwidth = input$binwidth, xlim = input$range)
  }, res = 96)

  output$ttest <- renderText({
    t_test(x1(), x2())
  })
}

Essa transformação produz o gráfico substancialmente mais simples.

• Agora, quando você altera binwidth ou range, apenas o gráfico muda, não os dados subjacentes.

No Shiny, acho que você deve considerar a regra de um: sempre que você copiar e colar algo uma vez, considere extrair o código repetido em uma expressão reativa.

• A regra é mais rígida para o Shiny porque as expressões reativas não apenas tornam mais fácil para os humanos entenderem o código, mas também melhoram a capacidade do Shiny de executar novamente o código com eficiência.

Por que precisamos de expressões reativas?

1. Se você tentar usar uma variável para reduzir a duplicação, poderá escrever algo assim:

server <- function(input, output, session) {
  x1 <- rnorm(input$n1, input$mean1, input$sd1)
  x2 <- rnorm(input$n2, input$mean2, input$sd2)

  output$hist <- renderPlot({
    freqpoly(x1, x2, binwidth = input$binwidth, xlim = input$range)
  }, res = 96)

  output$ttest <- renderText({
    t_test(x1, x2)
  })
}

• Se você executar esse código, receberá um erro porque está tentando acessar valores de entrada fora de um contexto reativo.

• Mesmo se você não obtivesse esse erro, ainda teria um problema: x1 e x2 só seria computado uma vez, quando a sessão começasse.

2. Se você tentar usar uma função, o aplicativo funcionará:

server <- function(input, output, session) { 
  x1 <- function() rnorm(input$n1, input$mean1, input$sd1)
  x2 <- function() rnorm(input$n2, input$mean2, input$sd2)

  output$hist <- renderPlot({
    freqpoly(x1(), x2(), binwidth = input$binwidth, xlim = input$range)
  }, res = 96)

  output$ttest <- renderText({
    t_test(x1(), x2())
  })
}

Mas tem o mesmo problema que o código original: qualquer entrada fará com que todas as saídas sejam recalculadas, e o teste t e o polígono de frequência serão executados em amostras separadas.

Expressões reativas armazenam automaticamente seus resultados em cache e são atualizadas apenas quando suas entradas mudam.

Controlando o tempo de avaliação

Para explorar as ideias básicas, vou simplificar o aplicativo de simulação.

ui <- fluidPage(
  fluidRow(
    column(3, 
      numericInput("lambda1", label = "lambda1", value = 3),
      numericInput("lambda2", label = "lambda2", value = 5),
      numericInput("n", label = "n", value = 1e4, min = 0)
    ),
    column(9, plotOutput("hist"))
  )
)
server <- function(input, output, session) {
  x1 <- reactive(rpois(input$n, input$lambda1))
  x2 <- reactive(rpois(input$n, input$lambda2))
  output$hist <- renderPlot({
    freqpoly(x1(), x2(), binwidth = 1, xlim = c(0, 40))
  }, res = 96)
}

Ao clicar

Talvez você queira exigir que o usuário opte por realizar o cálculo caro exigindo que ele clique em um botão.

• Este é um ótimo caso de uso para um actionButton():

ui <- fluidPage(
  fluidRow(
    column(3, 
      numericInput("lambda1", label = "lambda1", value = 3),
      numericInput("lambda2", label = "lambda2", value = 5),
      numericInput("n", label = "n", value = 1e4, min = 0),
      actionButton("simulate", "Simulate!")
    ),
    column(9, plotOutput("hist"))
  )
)

Para usar o botão de ação, precisamos aprender uma nova ferramenta.

• Como acima, nos referimos a simulate sem usar seu valor para obter uma dependência reativa dele.

server <- function(input, output, session) {
  x1 <- reactive({
    input$simulate
    rpois(input$n, input$lambda1)
  })
  x2 <- reactive({
    input$simulate
    rpois(input$n, input$lambda2)
  })
  output$hist <- renderPlot({
    freqpoly(x1(), x2(), binwidth = 1, xlim = c(0, 40))
  }, res = 96)
}

Isso não atinge nosso objetivo porque apenas introduz uma nova dependência: x1() e x2() será atualizado quando clicarmos no botão simular, mas eles também continuarão a atualizar quando alterar lambda1, lambda2, ou n.

• Queremos substituir as dependências existentes, não adicioná-las.

Para resolver este problema, precisamos de uma nova ferramenta: uma maneira de usar valores de entrada sem ter uma dependência reativa deles.

• Precisamos de eventReactive(), que tem dois argumentos: o primeiro argumento especifica sobre o que tomar uma dependência e o segundo argumento especifica o que computar.

server <- function(input, output, session) {
  x1 <- eventReactive(input$simulate, {
    rpois(input$n, input$lambda1)
  })
  x2 <- eventReactive(input$simulate, {
    rpois(input$n, input$lambda2)
  })

  output$hist <- renderPlot({
    freqpoly(x1(), x2(), binwidth = 1, xlim = c(0, 40))
  }, res = 96)
}

A Figura abaixo mostra o novo gráfico reativo.

• Observe que, conforme desejado, x1 e x2 não tem mais uma dependência reativa em lambda1, lambda2 e n.

Observadores

observeEvent() é muito parecido com eventReactive().

• Tem dois argumentos importantes: eventExpr e handlerExpr.

• O primeiro argumento é a entrada ou expressão da qual tomar uma dependência; o segundo argumento é o código que será executado.

• Por exemplo, a seguinte modificação server() significa que toda vez que name for atualizado, uma mensagem será enviada ao console:

ui <- fluidPage(
  textInput("name", "What's your name?"),
  textOutput("greeting")
)

server <- function(input, output, session) {
  string <- reactive(paste0("Hello ", input$name, "!"))
  
  output$greeting <- renderText(string())
  observeEvent(input$name, {
    message("Greeting performed")
  })
}

Existem diferenças importantes entre observeEvent() e eventReactive():

• Você não atribui o resultado de observeEvent() a uma variável, então:

• Você não pode se referir a ele de outros funcões reativas.

Layouts de página única

As funções de layout fornecem a estrutura visual de alto nível de um aplicativo.

• Os layouts são criados por uma hierarquia de chamadas de função, onde a hierarquia em R corresponde à hierarquia no HTML gerado.

• Isso ajuda você a entender o código de layout.

  fluidPage( 
    titlePanel("Hello Shiny!"), 
    sidebarLayout( 
      sidebarPanel( 
        sliderInput("obs", "Observations:", min = 0, max = 1000, value = 500) ), 
      mainPanel( plotOutput("distPlot") ) 
      ) 
    )

  
  

Concentre-se na hierarquia das chamadas de função:

fluidPage(
  titlePanel(),
  sidebarLayout(
    sidebarPanel(),
    mainPanel()
  )
)

Mesmo que você ainda não tenha aprendido essas funções, você pode adivinhar o que está acontecendo lendo seus nomes.

Funções da página

A função de layout mais importante, mas menos interessante, é fluidPage()

• fluidPage() configura todo o HTML, CSS e JavaScript que o Shiny precisa.

Além de fluidPage(), Shiny fornece algumas outras funções de página que podem ser úteis em situações mais especializadas: fixedPage() e fillPage().

• fixedPage() funciona como fluidPage(), mas tem uma largura máxima fixa, o que impede que seus aplicativos se tornem excessivamente amplos em telas maiores.

• fillPage() preenche toda a altura do navegador e é útil se você quiser fazer um gráfico que ocupe toda a tela. Você pode encontrar os detalhes em sua documentação.

Página com barra lateral

Para criar layouts mais complexos, você precisará chamar funções de layout dentro de fluidPage().

• Por exemplo, para fazer um layout de duas colunas com entradas à esquerda e saídas à direita, você pode usar sidebarLayout()(junto com seus amigos titlePanel(), sidebarPanel() e mainPanel()).

  fluidPage( 
    titlePanel( \# app title/description ), 
    sidebarLayout( 
      sidebarPanel( \# inputs ), 
      mainPanel( \# outputs ) 
      ) 
    )

Para torná-lo mais realista, vamos adicionar uma entrada e uma saída para criar um aplicativo muito simples que demonstra o Teorema do Limite Central

ui <- fluidPage(
  titlePanel("Central limit theorem"),
  sidebarLayout(
    sidebarPanel(
      numericInput("m", "Number of samples:", 2, min = 1, max = 100)
    ),
    mainPanel(
      plotOutput("hist")
    )
  )
)
server <- function(input, output, session) {
  output$hist <- renderPlot({
    means <- replicate(1e4, mean(runif(input$m)))
    hist(means, breaks = 20)
  }, res = 96)
}

Várias linhas

• Como de costume, você começa com fluidPage().

• Em seguida, você cria linhas com fluidRow() e colunas com column().

fluidPage( 
  fluidRow( 
    column(4, ... ), column(8, ... ) ), 
  fluidRow( column(6, ... ), column(6, ... ) ) 
)

Cada linha é composta por 12 colunas e o primeiro argumento para column() fornece quantas dessas colunas devem ser ocupadas.

• Um layout de 12 colunas oferece flexibilidade substancial porque você pode criar facilmente layouts de 2, 3 ou 4 colunas ou usar colunas estreitas para criar espaçadores.

Layouts de várias páginas

À medida que seu aplicativo cresce em complexidade, pode se tornar impossível ajustar tudo em uma única página.

Tabsets

A maneira simples de quebrar uma página em pedaços é usar tabsetPanel() e seu amigo próximo tabPanel().

• tabsetPanel() cria um container para qualquer número de tabPanels(), que por sua vez pode conter quaisquer outros componentes HTML.

ui <- fluidPage( 
        tabsetPanel( 
          tabPanel("Import data", 
            fileInput("file", "Data", buttonLabel = "Upload..."),
            textInput("delim", "Delimiter (leave blank to guess)", ""), 
            numericInput("skip", "Rows to skip", 0, min = 0),
            numericInput("rows", "Rows to preview", 10, min = 1) ), 
          tabPanel("Set parameters"), tabPanel("Visualise results") 
        )
      )

Se você quiser saber qual guia um usuário selecionou, você pode fornecer o argumento id de tabsetPanel() e ele se torna uma entrada.

ui <- fluidPage(
  sidebarLayout(
    sidebarPanel(
      textOutput("panel")
    ),
    mainPanel(
      tabsetPanel(
        id = "tabset",
        tabPanel("panel 1", "one"),
        tabPanel("panel 2", "two"),
        tabPanel("panel 3", "three")
      )
    )
  )
)
server <- function(input, output, session) {
  output$panel <- renderText({
    paste("Current panel: ", input$tabset)
  })
}

Listas de navegação e barras de navegação

Como as guias são exibidas horizontalmente, há um limite fundamental para quantas guias você pode usar, principalmente se tiverem títulos longos.

• navbarPage() e navbarMenu() fornecem dois layouts alternativos que permitem usar mais guias com títulos mais longos.

• navlistPanel() é semelhante, tabsetPanel() mas em vez de executar os títulos das guias horizontalmente, ele os mostra verticalmente em uma barra lateral.

ui <- fluidPage( 
    navlistPanel( id = "tabset", "Heading 1", 
      tabPanel("panel 1", "Panel one contents"), "Heading 2", 
      tabPanel("panel 2", "Panel two contents"), 
      tabPanel("panel 3", "Panel three contents") 
    ) 
  )

Outra abordagem é usar navbarPage(): ele ainda executa os títulos das guias horizontalmente, mas você pode usar navbarMenu() para adicionar menus suspensos para um nível adicional de hierarquia.

ui <- navbarPage(
  "Page title",   
  tabPanel("panel 1", "one"),
  tabPanel("panel 2", "two"),
  tabPanel("panel 3", "three"),
  navbarMenu("subpanels", 
    tabPanel("panel 4a", "four-a"),
    tabPanel("panel 4b", "four-b"),
    tabPanel("panel 4c", "four-c")
  )
)